Modern public-switched telephone networks (PSTN) use a signaling protocol, e.g. signaling system No. 7 (SS7) for switching of telephone calls. Signaling messages are transported in a signaling network separate from bearer channels. To enable the transport of SS7 signaling over an internet protocol (IP) based network, the Signaling Transport (SIGTRAN) working group of the internet engineering taskforce (IETF) has defined a set of SIGTRAN protocols. Examples of such protocols are the message transfer part 3 (MTP3) user adaptation (M3UA) protocol or the signaling connection control part (SCCP) user adaptation (SUA) protocol. An interworking between SS7 protocols and their corresponding user adaptation protocols is performed at a signaling gateway (SG), which generally terminates underlying protocol layers both on the SS7 and the IP side.
There are generally three types of signaling processes defined in SIGTRAN that can use a user adaptation protocol for a transport of signaling messages. These processes are a signaling gateway process (SGP), an application server process (ASP) and an IP server process (IPSP). For a communication between these processes, three different types of interfaces are defined: a SGP to ASP interface, an ASP to SGP interface and an IPSP to IPSP interface. These interfaces are incompatible, as e.g. only certain types of messages are allowed to be sent via a particular interface. The SIGTRAN protocols thus define interfaces which depend on the type of communication process and which are asymmetrical, i.e. for which the direction of communication matters. Details on such protocols can be found in RFC 3868 for the SUA protocol and RFC 4666 for the M3UA protocol.
To provide a communication between different types of network nodes in a SIGTRAN network architecture, SIGTRAN relay nodes are used to convert any possible interface of a SIGTRAN layer to any interface of the same SIGTRAN layer to perform interworking of SIGTRAN management procedures and to relay application messages.
FIG. 1 shows a SIGTRAN M3UA relay node comprising one or more own signaling processes of IPSP, ASP and SGP types performing mapping of parameters and messages according to the type of destination signaling process and to the local configuration in the relay node. A message sent by one of the remote signaling processes is routed by the relay node towards the remote signaling processes, in dependence on incoming message parameter values. The relay node according FIG. 1 further comprises local signaling processes. Solid black lines between the local signaling processes indicate that an interworking may be performed. For an incoming message received at local ASP, an address mapping and conversion of the message may be performed and the message may be sent to SGP via the local ASP.
A SIGTRAN network may comprise plural relay nodes. Messages may thus be routed via these plural relay nodes. In such a relay network, functions can be centralized at the relay nodes and do not need to be provided in each network node.
One of the key roles of relay nodes consists in interworking of management procedures in SIGTRAN networks, which provides for stability of signaling transport in the network. Depending on the types of supported interfaces and network management messages, the SIGTRAN signaling gateways, relay nodes and the SIGTRAN signaling endpoints (SEP) are open for processing of specified management messages that might change availability of network elements and application parts in the network. The type of the network management messages or the type of traffic maintenance messages sent is determined by the type of the remote signaling process towards which the respective message is sent. As an example, a SS7 congestion (SCON) message or a destination user part unavailable (DUPU) message may be sent to an ASP as a response to an earlier DATA message, whereas an ASP active (ASPAC) message or an ASP inactive (ASPIA) message may be sent to a SGP.
To relay or route network management messages to remote network nodes in a SIGTRAN network, the relay node has to translate a routing context by identifying an incoming routing key (RK) which is associated with the incoming management message based on a routing context (RC) parameter comprised in the incoming management message. On the basis of the incoming routing key or on the basis of the incoming routing key in combination with address-related parameters comprised in the incoming management message, an outgoing routing key is determined for the outgoing message. A routing context corresponding to the outgoing routing key is then assigned to the outgoing message. A routing key may for example identify a remote network node serving a particular traffic range and can consist of several destination point codes or can consist of destination and origination point code combination.
In situation when congestion occurs in a SS7 network in response to incoming traffic, a transfer controlled (TFC) message is generated including a destination point code (DPC) parameter as part of the MTP3 routing label. Routing of network management messages in a SS7 network is only based on the DPC parameter. If the originator of a message which triggered the TFC message is located in a SIGTRAN network, the TFC is sent to the SG node. The SG node converts the TFC message into a SCON message. The SCON message does not contain the concerned destination parameter, because, based on the RFC 4666 standard, the concerned destination parameter in a SCON message is only used if the SCON message is sent from an ASP to the SGP. Therefore, in the SG node, no mapping of the received DPC parameter from the TFC message to a concerned destination parameter of a SCON message will occur.
Another situation relates to a case wherein a remote peer MTP3-User Part at an SS7 node is unavailable. An UPU message is sent to the SG node which transfers the UPU message into a DUPU message without mapping the DPC to a concerned destination parameter.
In situations when the routing context parameter, included in a received DUPU or SCON message, does not identify uniquely a destination signaling endpoint, which is concerned about the user part unavailability or the congestion event, a SIGTRAN relay node is not able to relay the DUPU or SCON message to its destination. RFC 4666 suggests that SG nodes forward the DUPU and SCON messages to all AS's serving traffic for concerned destinations to assure that these network management messages will reach the concerned nodes. In some implementations and network scenarios with multiple signaling relay nodes, inappropriate sending of SCON and DUPU messages would lead to traffic disturbance and message multiplication at transfer of congestion information and user part unavailability information.